Perimeter Defense - Email Security > [T1]: Protecting Against Email Spoofing with DMARC
Now that we explained how SPF and DKIM work, it’s important to
mention that both protocols do not provide solid protection against
email spoofing because of how the verification process works. As
strange as it may sound, DKIM and SPF verification have nothing to
do with the FROM header -where spoofing happens. A
message can have a spoofed sender in the FROM
header and pass SPF / DKIM verification. For example, SPF is
ineffective on hosted services like 365, AWS, and Google mail, since
all customers use the same SPF record and share sending mail
servers.
SPF verification PASS means that the sending server IP address is
authorized in the SPF record of the domain in the
Return-Path header and not the
domain in the From header.
Return-Path is the email address that receiving
servers use to notify the sending mail server of delivery problems,
like bounces.
Figure - zoom in
On the other side, DKIM verification
PASS means that the received message was
digitally signed by the private key corresponding to the public key
published on the DNS server of the domain in the DKIM signature
header (d=) tag. Like SPF, it has nothing to do with the domain in
the From header.
Figure - zoom in
From a security/spoofing perspective, we are concerned more with the FROM header-which displays the sender’s name and email address- because this is what recipients see in their email clients. As with the following example, the FROM header was manipulated to spoof the identity of Amazon support.
Figure - zoom in
SPF and DKIM limitations created the need to fill this gap and protect against email spoofing, mainly the FROM header. This is what the DMARC protocol does.
DMARC -Domain-based Message Authentication, Reporting & Conformance- is an email authentication, policy, and reporting protocol. It uses SPF and DKIM to verify that the address in the ‘From’ header is the actual sender of the message. An email to pass DMARC must either pass and align SPF OR pass and align DKIM. We explained earlier what SPF/ and DKIM PASS mean. But what about SPF/DKIM alignment?
Aligned SPF means the domains in both “Return-Path” and “From” headers match. Aligned DKIM means the domains in the “DKIM signature d=” header and “From” header match.
Figure - zoom in
By requiring either SPF or DKIM to be aligned, DMARC offers robust protection against email spoofing.
DMARC also provides security analysts with two critical things that SPF and DKIM do not offer:
- Control: With SPF and DKIM, it is up to the receiving server to decide what to do with messages that fail SPF/DKIM verification. DMARC takes this further and provides domain owners complete control to set a policy to reject or quarantine emails that fail the verification process. It lets you tell receiving mail servers how you want them to behave if they received a spoofed message from your domain.
- Visibility: DMARC provides domain owners with visibility and reports on who is sending emails from their domains, ensuring legitimate emails only are received. It provides a way for the receiving server to report messages that pass or fail the DMARC evaluation to the sending domain.
DMARC records are published as TXT records in the DNS server, just like DKIM and SPF. To check the DMARC record for a domain, we query the DNS server for _dmarc.<domain>. Look at a live example and check the DMARC record for nsa.gov. We can do this by executing the following command
| dig _dmarc.nsa.gov TXT | grep dmarc |
Figure - zoom in
As we can see, the DNS server for nsa.gov responded with the DMARC record for the nsa.gov domain. Let’s break it down:
- v=DMARC: The DMARC version should always be “DMARC1”. A wrong or absent DMARC version tag would cause the entire record to be ignored.
- p=quarantine: Policy applied to emails that fail the DMARC check. Available options are: “none”, “quarantine”, and “reject”. “none” is used to collect feedback and gain visibility into email streams without impacting existing flows. “quarantine” allows mail receivers to treat email that fails the DMARC check as suspicious. They will often end up in your SPAM folder. “reject” outright rejects all emails that fail the DMARC check.
- fo=1: Forensic reporting options.
Available options are: “0”,
“1”, “d”, or
“s”.
- “0” generates reports if both SPF and DKIM fail.
- “1” generates reports if SPF or DKIM fails.
- “d” generates reports if DKIM only failed verification.
- “s” generates reports if SPF only failed verification.
- rua=mailto:DMARC_REPORTING@nsa.gov: tells receiving servers where to send aggregate reports. Aggregate reports are very important and contain the authentication status for SPF, DKIM, and DMARC. These reports don’t have sensitive information from the email itself. Instead, it includes diagnostic information like the IP that sent the message and whether SPF/DKIM verification passed or failed.
- ruf=mailto:DMARC_REPORTING@nsa.gov: tells receiving servers where to send forensic reports. A more detailed reporting option is intended to provide domain owners with redacted email copies that failed the DMARC check.
- rf=afrf: The reporting format for individual Forensic reports. Available options are: “afrf”, “iodef”.
- pct=100: tells the receiving server the percentage of incoming mails to apply DMARC policy on that domain (for messages that fail verification). In this example, NSA is telling receiving servers to quarantine 100% of messages from @nas.gov if they fail DMARC.
Let’s look at another example. Here is the DMARC record for google.com
Figure - zoom in
Here we can see that Google has a REJECT policy which means that any receiving server should drop all messages coming from @google.com if they fail DMARC. Unlike nsa.gov, where the policy is set to Quarantine.